Programmable automation controllers (PACs) and their associated control programming are at the heart of modern industrial automation systems. These controllers interact with field devices on the plant floor to carry out controlled processes relating to such objectives as manufacture of a product, movement of material through a system, and other such processes. The controllers typically exchange data with the field devices using native hardwired I/O or via a plant network such as Ethernet, Data Highway Plus, Devicenet, or the like. The controller receives any combination of digital or analog signals from the field devices indicating a current state of the devices (e.g., temperature, position, part presence or absence, fluid level, etc.), and executes a control program that performs automated decision-making for the process based on the received signals. The controller then outputs appropriate digital and/or analog control signaling to the field devices in accordance with the decisions made by the control program. These outputs can include component actuation signals, temperature or position control signals, commands to a machining or material handling robot, and the like. The control program executed by the controller can comprise any conceivable type of code used to process input signals read into the controller and to control output signals from the controller, including but not limited to ladder logic, sequential function charts, function block diagrams, structured text, or other such platforms.
To facilitate operator interaction with the PACs (and with the processes controlled thereby), industrial control systems often include at least one human-machine interface (HMI) that communicates with the PAC and visualizes data therein one or more display screens. The HMI screens also allow an operator to issue commands (e.g., machine start commands) or write values (e.g., setpoint values) to the PAC to control or alter the process being automated by the PAC. Often, commands issued through the HMI to trigger an action in the PAC (e.g., to start a machine cycle or to actuate a field component) are subject to one or more conditions that must be satisfied before the desired action can be performed. For example, a command to start a machine's auto cycle may require that certain part positioning or tooling devices are in a home position and a mode switch to be set to an “AUTO” position before the cycle is allowed to begin. In such an instance, the control program will typically include these criteria as conditions that must be met before the controller output that initiates the auto cycle will be energized. Sensors on the field devices report the respective positions thereof to the PAC as inputs, and the controller program either allows or prevents the desired action based on the values of these inputs. Similarly, a command issued through the HMI to actuate a field component may be prevented by the control program if another movable field component is in an extended position that would physically interfere with the desired actuation. Again, the control program executing in the PAC reads the values of position sensors associated with the potentially interfering devices and prevents the controller output associated with the desired actuation from energizing if the sensor values indicate a potential interference.
In module-based control programs, external system conditions such as those listed above can be programmatically associated with a given module as one or more permissives or interlocks, such that the ability to issue a command to the given module depends on all associated permissives and interlocks being in a correct state. In addition to conditions external to the PAC, a module's readiness to receive and respond to an operator-issued command can further be a function of one or more internal program statuses. For instance, the ability to issue a command to a given module (e.g., a module associated with a valve) can be permitted or denied based on such internal conditions as the current mode of the module, the module's present state, or the module's configured capabilities.
Modern industrial automation systems often comprise many such complex interdependencies between physical components, system states, operating modes, manual control devices, and the like. System engineers set out to design control programs that take these many system dependencies into consideration in an effort to ensure proper coordination of various processes that make up an automation system, as well as to guarantee safety of personnel. However, from the point of view of a system operator, who typically is not involved in the system design process and therefore is not necessarily conversant with the low-level system interactions, these complex system dependencies often make it difficult to ascertain why a desired command issued by an HMI is being prevented from executing.
HMIs are often designed such that screen elements (e.g. soft buttons, data entry fields, etc.) designed to allow manual commands to be issued to the PAC are disabled on the HMI screen if one or more permissives associated with the desired action are not met. These screen elements are sometimes visually altered (e.g., “greyed out” or rendered invisible) to convey to the operator that one or more prerequisites are not met. However, it is left to the operator to determine which conditions are preventing the desired command from being issued. Diagnosis of such command failures relies upon the particular operator's knowledge of the automation system, which is often a function of experience. If the operator is unable to locate the missing conditions preventing a command from being carried out, it may even be necessary for maintenance personnel or a plant engineer to go online with the PAC to track the missing permissives in the control program before an operator can set about correcting the missing conditions. Although custom display screens can be developed for the HMI that list the conditions for a given action together with their respective states, such screens must be created and programmed by a system developer and manually linked to the program addresses associated with the respective conditions, increasing development time and adding complexity to the HMI application. Moreover, if an engineer or maintenance personnel subsequently modify the control program to add or remove a condition for a control action, such custom screens must then be modified accordingly by the HMI developer to reflect the changes.
Given the difficulties diagnosing such command failures, there is a need for an operation diagnostic tool that can be easily deployed to visualize diagnostic permissive information for HMI-issued commands.